Configure episode action rules in ITSI

Set up action rules within an aggregation policy in IT Service Intelligence (ITSI) to take automated actions when an episode's activation criteria are met. Action rules are optional. You can define more than one action rule per aggregation policy. For more information about aggregation policies, see Overview of aggregation policies in ITSI.

For example, if you want to close the episode and change the episode severity level to Info when a notable event comes in, you could specify the following rule:

If the following event occurs: severity matches Normal, change severity to Info for the episode, add a comment Don't worry for the episode, and change status to Closed for the episode.

Action rules consist of the following distinct parts:

Component	Description
Activation Criteria	A set of WHERE clauses that determine when the trigger conditions for a specific action are met.
Action	A set of THEN clauses that represent the things being done to an episode when the activation criteria are met. Examples of actions taken on episodes include changing the status, severity, or owner of an episode. Actions can also be taken on things other than the specific episode that triggered the action. Examples of external actions include pinging a host, sending an email, or creating a ticket in an external ticketing system.

Activation criteria

Choose from the following conditions that trigger an action:

Trigger condition	Notes
The following event occurs	Trigger an action when an event containing specific field values is added to the episode. For example, when severity matches Critical. You can match on any fields in the event. The syntax for the field value does not follow standard SPL. The value must exactly match the field value in the event, including capitalization and spaces. You can use asterisks (*) as wildcards (for example, service_name does not match BG_*
The episode existed for	Trigger an action if the episode has existed for a given amount of time, in seconds. You might close an episode if it's existed for 86400 seconds (one day).
The number of events in the episode is	Trigger an action if the number of events in the episode exceeds or does not reach a certain limit. By default, an episode breaks when it reaches 10,000 events, and a new episode is created. Note: Every incoming notable event executes an action until the limits set for the "greater than or equal to" and "less than or equal to" matching conditions are met. Ensure the limits set are accurate to avoid duplicate actions for the same episode.
The flow of events into the episode paused for	Trigger an action if the episode hasn't received any events for a given amount of time, in seconds. The maximum value for this field is 86400 seconds (24 hours).

You can enable time-based actions to run only one time per episode by enabling the Run Time-Based Actions Once toggle on the Notable Event Aggregation Policy page. For example, if you create an action to add a comment after an episode has existed for 60 seconds, a comment will only be added once for the episode. There are 2 conditions that trigger time-based actions:

• The episode existed for
• The flow of events into the episode paused for

Action rules

Choose from the following actions to take on an episode:

Action	Notes
Change severity	For example, change the severity to Critical when the number of events in the episode is greater than 100.
Change status	For descriptions of each status, see Update the status of an episode. Changing an episode's status to Closed through an aggregation policy action rule also breaks the episode so it no longer receives events.
Change owner	Episodes are unassigned by default.
Add a comment	Does not accept token replacement.
Ping a host	Determine whether a host is still active on the network by pinging the host. Provide the event field that contains the host that you want to ping in the Host field. For example, %server%.
Send an email	Send an email to the appropriate team as a result of an event. Make sure the mail server is configured in the Splunk platform before configuring this action. For Splunk Enterprise, see Configure email notification settings in the Splunk Enterprise Alerting Manual. For Splunk Cloud Platform, see Configure email notification settings in the Splunk Cloud Platform Alerting Manual. You can use tokens in the email subject or message. The tokens are replaced with field values in the email message. The following episode fields are available: owner severity status title description start_time last_time is_active event_count You can also use fields contained in the last event in the episode. If a field isn't present in the last event, although it may exist in other events in the episode, ITSI does not replace the token with the field value in the email message. Optionally, select a message template which populates the message field with a preconfigured email body. Tokens are supported in templates. Click Manage templates to configure additional templates or remove existing ones. Anyone with the admin, itoa_admin, or itoa_analyst role can create and edit email templates. Once you create a template it's available for selection in all aggregation policies and is not policy-specific.
Run a script	Provide the file name of the script stored in $SPLUNK_HOME/bin/scripts. For more information, see Configure scripted alerts in the Splunk Enterprise Alerting Manual. Note: The run a script functionality is officially deprecated and will be removed in a future release. It will be replaced with custom alert actions as a more scalable and robust framework for integrating custom actions. For more information about custom alert actions, see Create custom alert actions for Splunk Cloud Platform or Splunk Enterprise in the Developer Guide on the Splunk Developer Portal.
Webhook	Send episode data using a webhook. Provide a name for the webhook and validate the webhook URL.

External episode actions

In addition to the default episode actions included with ITSI, you can also integrate with certain third-party alerting systems. Once you configure an integration, you can set up action rules that create tickets in those third-party systems when certain activation criteria are met.

ITSI offers the following external actions you can take within integrated systems:

Action	Notes
Create an incident in ServiceNow	Requires the Splunk Add-on for ServiceNow. For configuration information, see Integrate ITSI with ServiceNow.
Create an incident in BMC Remedy	Requires the Splunk Add-on for BMC Remedy. For configuration information, see Integrate ITSI with BMC Remedy.
Create an incident in Splunk On-Call (VictorOps)	Requires Splunk On-Call. For configuration information, see Integrate ITSI with Splunk On-Call (VictorOps).
Create a Jira issue	Requires the Splunk Add-on for Jira Cloud. For configuration information, see Integrate ITSI with Splunk Add-on for Jira Cloud.

For more information about the integrations shipped with ITSI, see Overview of episode ticketing integrations in ITSI.